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1.0 Scope 

1.1 Identification 

This document applies to the Extended Testability Analysis (ETA) Tool software, Version 6.7, release 1.0. 

1.2 System Overview 

The purpose of the ETA Tool software is to process the testability analysis results from the Testability Engineering 
And Maintenance System (TEAMS) Designer program and provide the user with detailed documentation of the 
results. The TEAMS Designer is commercial-off-the-shelf software with the capability to analyze a diagnostic 
model of the system under study. The diagnostic model is a directed graph representation of the failure effect 
propagation paths within the system’s physical architecture. The ETA Tool extracts information from the TEAMS 
Designer analysis output and the associated diagnostic model to provide a detailed set of reports highlighting aspects 
of the system’s diagnostic performance. The ETA Tool was developed under the NASA Constellation Program to 
support the Functional Fault Analysis (FFA) team for the Ares I Launch Vehicle. 

The ETA Tool software was initially developed in response to system engineering requests to summarize the 
testability results from the diagnostic model and was extended to incorporate specific system information captured 
within the diagnostic model. The ETA Tool relies on the testability analysis output from TEAMS Designer and the 
diagnostic modeling conventions established by the Ares I FFA team (Appendix A). Flowever, the version of the 
tool associated with this user manual was generalized for public distribution and application to a broad spectrum of 
systems requiring testability analysis. 

1.3 Document Overview 

This user manual describes the implementation and use of the ETA Tool software. The manual first provides an 
overview of the software package. It then provides directions for software installation, setup, and execution. The 
ETA Tool is a command line process with several user-selectable report output options. Example reports used to 
demonstrate the output options were generated for a generic system, the details of which are provided in 
Appendix B. The intent of this manual is to provide the user the information needed to operate the ETA Tool 
successfully and generate specific testability analysis reports. This manual is not intended to educate the user in the 
operation of the TEAMS Designer software package nor in the broader context of diagnostic analysis and 
assessment. 


1.4 Formats and Conventions 

Sans-serif Directory names, file names, function names and screen output are displayed in this 

font. For example: xls2csv.exe 

Italics Book or report titles and names of book or report sections, mathematical symbols 

and notation, and the introduction of new terms. For example: Introduction 


2.0 Referenced Documents 


Documents referenced in this report are listed below 


Document number 

NPR 7150.2 
GLPR 7150.1 
GRC-TPLT-SUM 
MIL-STD-1629A 

<TBD> 


Title 

NASA Software Engineering Requirements 
GRC Software Engineering Requirements 
Software Users Manual Template 

Military’ Standard Procedures for Performing a Failure Mode, Effects and 
Criticality Analysis 

NASA Constellation Program Fault Management Terminology’ Report, Johnson, 
S.B.; and Day, J.C.: September 10, 2010 (unpublished). 
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3.0 Software Summary 

3.1 Software Application 

The ETA Tool extracts information from the TEAMS Designer analysis output and the associated diagnostic model 
to provide a detailed set of reports highlighting aspects of the system’s diagnostic performance. Here, diagnostic 
performance implies the systems ability to detect the effects propagated from failure modes and to isolate system 
faults or faulty components The TEAMS testability analysis is performed on a diagnostic model of a physical 
system. The testability results and the diagnostic model are accessed by the ETA Tool so that further processing can 
extend the testability analysis. The extended analysis provides failure effect detection and fault isolation information 
in a consistent report format. The ETA Tool is capable of generating the following extended analysis reports: 

• Detectability Report provides details that show how each tested failure mode was detected 

• Test Utilization Report identifies all failure modes detected by each system test. 

• Failure Mode Isolation Report demonstrates the ability of the system to discriminate between failure 
modes. 

• Component Isolation Report demonstrates the ability of the system to discriminate between failure modes 
relative to the components containing the failure modes. 

• Effect Mapping Report identifies failure modes that result in user specified system-level effects. 

• Sensor Sensitivity Analysis Reports describes the impact of the loss of a sensor on the ability of the 
system to detect and isolate the various failure modes. 

The ETA Tool reports can be converted into printable formats or viewed directly from computer Internet browsers. 

3.2 Software Inventory 

The following files are included in the ETA Tool, Version 6.7 — Release 1.0 package 
Basic_System <directory> 

• Contains files for the example diagnostic model, including an example testability output cycle for 
TEAMS Designer which can be used to demonstrate the ETA Tool. 

Sample Output <directory> 

• Contains the output file from an ETA Tool example case for the Basic_System model. 
Basic_System_sensor_file.csv <file> 

• Example sensor file in comma separated variable (CSV) format 

• Required for any ETA Tool analysis. 

Basic_System_Sensor_Sensitivity_Study.csv <file> 

• Example instrumentation information file in CSV format 

• Required for the sensor sensitivity analysis option 
ETAT_v6_7.c <ftle> 

• ETA Tool source code written in the C programming language 
ETAT_v6_7.exe <file> 

• Windows executable version of the ETA Tool 

• Compiled with GCC version 4.5.0 compiler using MinGW headers and libraries (10/30/2010 released 
package) 
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makefile <file> 

• Contains compiler directives used to compile, link, and create executable software 

• Tested using GCC version 4.5.0 compiler using MinGW headers and libraries (10/30/2010 released 
package) 

README File.docx <file> 

• Lists contents of the ETA Tool zip-file 

• Provides a brief example showing how to run the program 

• Contains code revision history 
set-env.bat <file> 

• Example DOS batch file to set a DOS environment variable for the highest-level directory used by 
the ETA Tool 

xls2csv.exe <file> 

• Windows executable program used by the ETA Tool internally to convert the EXCEL file to a 
comma-separated variable (CSV) file during processing 

XLStoCVS.vbs <file> 

• Visual basic script used to convert an EXCEL file to a CSV-formatted file. 

• Pre-compiled code for previously described xls2csv.exe executable. 

• Can be ran from a command window 

The software release package contains two directories: Basic_System and Sample Output. The first directory, 
named Basic_System, contains the diagnostic model from an example system. Under the Basic_System directory 
structure are two subdirectories; a model subdirectory that contains the TEAMS diagnostic model and a description 
subdirectory which contains two documents that detail the general design and operation of the example system 
modeled. The description directory in this package also contains an example output report set from the ETA Tool 
for the Basic_System model. The Sample Output directory contains sample analysis output files from a single 
processing cycle of the ETA Tool. 

3.3 Software Environment 

This section identifies the hardware and software resources that are required for a user to install and run the ETA 
Tool. The software is intended to be multi-platform operational. However, at this time, the software has only been 
tested with an Intel Processor-based Windows XP system. The program requires the following external software 
program: 

• The included executable has been compiled with the GCC (version 4.5.0) compiler using MinGW headers 
and libraries (10/30/2010 released package) 

The software has been developed and tested on the following platform: 

• Operating System: Microsoft Windows XP Professional 2002, Service Pack 3 

• Operating Platform: Q37 XPPro Multi Platform Load Intel® Core™ 2 Duo CPU T7500, 2.20 GHz, 3.5 GB 
RAM 
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3.4 Software Organization and Overview of Operation 

The ETA Tool executable and the xls2csv.exe file should be located in the same directory. The ETA Tool program 
is operated from the command line. The ETA Tool assumes that the system environmental variable TEAMS is 
defined prior to ETA Tool execution. This variable is used to define the location of the TEAMS diagnostic model on 
the hard drive of the user’s computer. The model information and testability reports used by the ETA Tool are stored 
by TEAMS in pre-defined subdirectories under the TEAMS directory. During execution, the ETA Tool will copy 
certain testability analysis output files to the local directory containing the ETA Tool executable and further process 
them. The program will also remotely access certain diagnostic model files to extract design information. Files 
containing final analysis reports from the ETA Tool will also be placed in the directory containing the ETA Tool 
executable. The types of reports generated will depend on the command line syntax used by the user to run the ETA 
Tool software. 


3.5 Security and Privacy 

The ETA Tool is Class E software as defined in Glenn Procedural Requirement (GLPR) 7150.1 GRC Software 
Engineering Requirements, developed with U.S. government funding. As such, it is free and available without 
restriction for use by the general public. The user accepts any risks to their system or damage or loss of data with the 
operation of this software program. 

3.6 Assistance and Problem Reporting 

This software is officially unsupported. If there are any issues or questions concerning the software, the user may 
contact the principal developer, but an immediate response should not be expected. Further, the government makes 
no guarantees regarding compatibility with operating system software or compilers with which the ETA Tool 
software has not been test. 


4.0 Software Operations 

4.1 Installation and Setup 

ETA Tool version 6.7 is packaged in a compressed file. The contents can all be extracted into a file directory that 
will be hence forth named ETAT_HOME directory. A list of files included in the compressed file is given in 
Section 3.2. 

A pre-compiled version of the ETA Tool is included for Windows-based computers. The makefile provides the user 
with an example that demonstrates the process for generating the ETA Tool executable. The file will need to be 
modified to reflect the available C compiler, compiler options and compiler location on the user’s computer. 

The ETA Tool expects a system environmental variable to be set prior to ETA Tool execution that defines the 
location of the TEAMS diagnostic model. The process for setting the environmental variable will be dependent on 
the computer platform and operating system. The ‘set-env.bat’ file included with the distribution package contains 
an example of syntax required to define the environmental variable for a DOS shell session. Also, it sets the 
environmental variable to reference the example model included in the package to allow exercising the ETA tool 
without requiring a TEAMS installation. Flowever, during normal use of the ETA tool, this command should be 
modified to reference the installed TEAMS diagnostic model. For example, 

» set TEAMS=C:\TEAMS\Basic_System\model 

Setting the environmental variable by running the batch file at the command line or by directly typing the ‘set’ 
commands, should define the variable for the current DOS shell session. Environmental variables can also be 
defined in Microsoft Windows in the ‘Control Panel’ under the ‘System’ icon. 

Two instrumentation files are required as inputs for the ETA Tool processing and must be created by the user prior 
to processing. In order for the ETA Tool to access these files, they must be placed in the same directory as the ETA 
Tool executable. These files contain basic design information that requires updating only if the instrumentation in 
the system under analysis is changed. 
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The first file is the sensor input file. This file, in a CSV format, is required for every ETA Tool analysis report. The 
sensor input file developed for the example system is provided as a template for use in creating customized sensor input 
files for user applications. The sensor input file for the example problem is named Basic_System_sensor_file.csv 
and is located in the ETAT_HOME directory. Table 1 displays a portion of this file. The following information is 
contained in the sensor input file: 

• Measurement Identifier — Required unique string that is used to identify the sensor. Within the diagnostic 
model, the test name should contain this string (see Appendix A — Diagnostic Modeling Conventions). The 
ETA Tool attempts to match these values to the “Measurement Identifier” field used in the test naming 
conventions of the diagnostic model. 

• Other Measurement Identifier — Optional measurement identifier that could be used in future reporting 
needs. The ETA Tool will also check to see if this string is utilized in the diagnostic model test naming 
convention field for “Measurement Identifier”. Often within a program instrumentation can have multiple 
identifiers that various groups employ. 

• Schematic Identifier — Optional identifier that represents the schematic design representation of the sensor. 
The ETA Tool uses this field to align the sensor to the proper hierarchical module within the diagnostic 
model. Reported if available. 

• 3 rd Measurement Identifier — Optional identifier that could be used in future reporting needs. Often within a 
program instrumentation can have multiple identifiers that various groups employ. 

• Subsystem — Optional. Portion of the system where the sensor resides. Currently not used by the ETA Tool. 

• Component — Optional. Lower level portion of the system where the sensor resides. Currently not used by 
the ETA Tool. 

• Short Description — Optional. Brief description of the sensor. 

If there are no entries for any of the optional columns, then the ‘None’ string is required. This file can have any 
name and can be specified as part of the command line syntax. If the naming convention, 

<Model Name>_sensor_file.csv is used, where the model name is the diagnostic model being evaluated, the ETA 
Tool will access the file from the current directory without command line specification. 


TABLE 1. — PORTION OF THE SENSOR INPUT FILE REQUIRED BY THE ETA TOOL PROCESSING 


Measurement 

Identifier 

Other 

Measurement 

Identifier 

Schematic 

Identifier 

3rd 

Measurement 

Identifier 

Subsystem 

Component 

Short Description 

SEN0001 

SEN0001 

SSI 

None 

Hydraulic 

Pump 

Assembly 

Turbine 

Pitch Turbine Speed 
Sensor 

SEN0002 

SEN0002 

SS2 

None 

Hydraulic 

Pump 

Assembly 

Turbine 

Yaw Turbine Speed 
Sensor 

SEN0003 

SEN0003 

PV11 

None 

Hydraulic 

Pump 

Assembly 

PSV 

Pitch Propellant 
Supply Valve 
Position 

SEN0004 

SEN0004 

PV12 

None 

Actuator 

PSV 

Pitch Pressure 
Selector Valve 
Position 

SEN0005 

SEN0005 

PV21 

None 

Hydraulic 

Pump 

Assembly 

PSV 

Yaw Propellant 
Supply Valve 
Position 

SEN0006 

SEN0006 

PV22 

None 

Actuator 

PSV 

Y aw Pressure 
Selector Valve 
Position 
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TABLE 2. — Concluded. 


Measurement 

Identifier 

Other 

Measurement 

Identifier 

Schematic 

Identifier 

3rd 

Measurement 

Identifier 

Subsystem 

Component 

Short Description 

SEN0007 

SEN0007 

dPl 

None 

Hydraulic 

Fluid 

Assembly 

Filter 

Pitch Delta Pressure 
Filter Sensor 

SEN0008 

SEN0008 

dP2 

None 

Hydraulic 

Fluid 

Assembly 

Filter 

Yaw Delta Pressure 
Filter Sensor 

SEN0009 

SEN0009 

Pll 

None 

Hydraulic 

Pump 

Assembly 

Turbine 

Pitch Turbine 
Propellant Inlet 
Pressure 

SEN0010 

SEN0010 

P12 

None 

Hydraulic 

Fluid 

Assembly 

None 

Pitch Hydraulic 
Supply Pressure 1 


The second sensor input file, the sensor sensitivity study input file, is only required when the sensor sensitivity 
analysis option is specified on the command line. The sensor sensitivity study input file for the example problem is 
named Basic_System_Sensor_Sensitivity_Study.csv and is located in the ETATJHOME directory. 

For illustrative purposes, a portion of the file is shown in Table 2. This file defines the sensor groupings for the 
analysis. The sensor sensitivity analysis cycles through the available sensors three times. The first pass removes 
individual sensors from the system and determines the diagnostic impact. During the second and third passes, groups 
of sensors are removed one group at a time. The first column in this file, Measurement Identifier, specifies the 
individual sensors to be analyzed in the sensor sensitivity analysis. The unique label must be identical to an entry in 
the basic sensor file, Measurement Identifier column, presented above. The second column in this sensor file, 
Group 1 Identifier, tags individual sensors with a group name that will be used to extract those sensors together 
during the second sensor sensitivity analysis cycle. The third column. Group 2 Identifier, performs the same 
function for the third sensor sensitivity analysis cycle. If a sensor is not involved in a group for the second or third 
analysis cycle, a ‘None’ entry is required in the respective columns. This file should be saved in a comma-separated- 
variable format. 


TABLE 3.— PORTION OF THE SENSOR INFORMATION INPUT FILE REQUIRED BY 
THE ETA TOOL SENSOR SENSITIVITY ANALYSIS PROCESSING 


Measurement 

Identifier 

Group 1 Identifier 

Group 2 Identifier 

SEN0001 

None 

Turbine Speed Sensor 

SEN0002 

None 

Turbine Speed Sensor 

SEN0003 

None 

Propellant Supply Valve Position 

SEN0004 

None 

Pressure Selector Valve Position 

SEN0005 

None 

Propellant Supply Valve Position 

SEN0006 

None 

Pressure Selector Valve Position 

SEN0007 

None 

Delta Pressure Filter Sensor 

SEN0008 

None 

Delta Pressure Filter Sensor 

SEN0009 

None 

Turbine Propellant Inlet Pressure 

SEN0010 

Pitch Hydraulic Supply Pressure 

Hydraulic Supply Pressure 

SEN0011 

Pitch Hydraulic Supply Pressure 

Hydraulic Supply Pressure 

SEN0012 

None 

Turbine Propellant Inlet Pressure 

SEN0013 

Yaw Hydraulic Supply Pressure 

Hydraulic Supply Pressure 

SEN0014 

Yaw Hydraulic Supply Pressure 

Hydraulic Supply Pressure 

SEN0015 

None 

Propellant Supply Valve Current 

SEN0016 

None 

Actuator Power Valve Solenoid Current 
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4.2 Basic Operation 

The ETA Tool program is executed from the DOS command line with user-selectable options. The following text 
provides a description of the proper syntax for the ETA Tool version 6.7; 

ETAT_v6_7 {-i ins file.csv} {-d} {-si ss_file.cvs} {-Dj {-T} {-E} {-1} {-iso label} 

where 


• {-i ins_file.cvs} 

• {-d} 

• {-si ss_file.cvs} 

• {-□} 

• {-T} 

• {-E} 

• {- 1 } 

• {-iso label} 


Specifies the CSV-formatted sensor file to use in the ETA Tool analysis. 
If this option is not specified, the ETA Tool will attempt to access a 
default sensor file by the naming convention 
“<Model Name>_sensor_file.csv” 

Indicates a debugging option which turns on certain screen printing 
output for ETA Tool developers. 

Indicates that the sensors sensitivity analysis is to be performed and the 
CSV-formatted file to use containing additional sensor information. 

Generates the Detectability Report 

Generates the Test Utilization Report 

Generates the Effect Mapping Report 

Generates the Failure Mode Isolation Report 

Generates the Component Isolation report and indicates the hierarchical 
label to be used in the component-isolation analysis 


Upon completion of the ETA Tool processing, a main output file is generated. The main output file is in HyperText 
Markup Language (HTML) format and is displayable within any of the common Internet browsers. It has been 
tested and is known to work correctly with Internet Explorer, 7.0, Mozilla Firefox 3.6.13, Google Chrome 9.0, 
Safari 5.0 and Opera 1 1.0 browsers. The naming convention for the main output file is as follows: 

< TEAMS diagnostic model «ame>_TestAnalysis_Main.htm 
The main output file for the example problem is: 

A ETAT_HOME \Basic_System_TestAnalysis_Main.htm 

The main output file has three sections separated by blue horizontal lines. The top section contains testability 
conditions for the analysis conducted by TEAMS. The second section contains hyper-linked documents from the 
TEAMS Designer testability analysis. These documents are not modified by the ETA Tool and are provided to the 
user for reference information. The last section contains hyper-linked documents of reports generated by the ETA 
Tool based on the options selected by the user at run time. Note that only the reports specified by the user as part of 
the command line syntax will be linked by the main report. Figure 1 illustrates an example of the ETA Tool main 
report file. 
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ETAT Analysis Summary 
Model Version: Basic_System 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

Ambiguity Isolation Level: 

Failurejnode 

System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1R_Phase-B 

Crit-3_Phase-B 

Crit-1S_Phase-B 

Crit-1_Phase-B 

Test Labels: 

Effect 

Flight 


TEAMS Analysis Links 

TEAMS Testability Figures of Merit (TFOM) Report 

TEAMS Ambiguity Report 

TEAMS Fault Detection A- Isolation Report 


ETAT Output Reports 

Detectability Report 

Test Utilization Report 

Effect Mapping Report 

Failure Mode Isolation Report 

Component Isolation Report 

Sensor Sensitivity Analysis by Individual Sensors 

Sensor Sensitivity Analysis by Measurements 

Sensor Sensitivity Analysis by Measurement Groups 


Figure 1 . — Main output report file generated by the ETA Tool software. 
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5.0 Processing Reference Guide 

This section provides a demonstration and explanation for each of the six ETA Tool reports. In addition, the output 
from a simple TEAMS model is used to demonstrate and explain the processes that generate each of the available 
ETA Tool reports. As part of the example, command line syntax for the various reports is discussed. 

5.1 Capabilities 

Each report output option is independent of the others. The user may select any or all of the options during a single 
processing cycle. 

5.2 Processing Procedures 

The command line syntax for each report will be discussed individually in subsequent subsections by describing any 
special input requirements and the resulting output report. In each case, the example system provided was utilized to 
generate the reports for illustration. 

5.2.1 Generation of the ETA Tool Detectability Report 

Syntax for generating a Detectability Report: 

» ETAT_v6_7.exe -D 

Special Input Requirements: 

None 

Output Report Description: 

The Detectability report generated for the example system provided in the software package is named: 

.\ETAT_HOME \Basic_System_Detectability_Report.htm. 

The report can be either opened directly into an Internet browser or accessed by the “Detectability Report’’ link on 
the main output file, BasicJ5ystem_TestAnalysis_Main.htm. 

The Detectability report provides details regarding the detection or missed detection of failure modes using the 
available suite of detection tests. This analysis and reporting capability proved useful during the design phase of 
NASA’s Ares I Project, when verifying the ability of subsystem designs to meet requirements regarding the 
detection of specific failure modes. The Detectability report identified the sensors and tests capable of providing 
detection of effects propagated by the failure mode. 

The Detectability report generated by this command line syntax may be found in the ETATHOME directory. 

Figure 2 illustrates the ETA Tool Detectability report for the example diagnostic model. The report contains three 
sections separated by a blue horizontal line. The top section lists the testability conditions for the analysis conducted 
by TEAMS. 

The second section contains metrics generated by the ETA Tool during the detectability analysis. 

• Number of Failure Modes — the number of failure modes that are active for the specified testability analysis 
conditions. 

• Number of Tests — the number of tests available for the specified testability analysis 

• Overall Detection Coverage — a calculated metric that is equal to the number of detected failure modes 
divided by the total number of failure modes 

This section also lists the failure modes, if any, that were not detected by any test during this analysis. For large lists 
of undetected failures (greater than 10 failure modes), a separate report is generated and hyper-linked to this section. 

The last section of this report presents information for each detected failure mode where results for the individual 
failure modes are separated by a green horizontal line. For each failure mode, the component from which the failure 
mode originated, the failure mode name, and Failure Mode and Effect Analysis (FMEA) number are reported. A 
table is reported containing the tests that detected the failure mode, including the sensor identifier, sensor description 
and test name. 
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ETAT Analysis Summary - Detectability Report 

Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1R_Phase-B 
Crit-3_Phase-B 
Crit-1 S_Phase-B 
Crit-1_Phase-B 
Test Labels: 

Effect 

Flight 


Detectability Analysis 


Number of Failure Modes 1 1 8 

Numbei of Tests 76 

Oveiall Detection Coverage 98 .31 % 


2 Undetected Failuie Mode(s) 


Component 

Failure Mode 

FMEA Identifier 

Hydraulic Turbine 

Propellant Leak 

MS-SS-HPump-0 1-002 

Hydraulic Turbine 

Propellant Leak 

MS-SS-HPump-0 1-002 


(1) Failure Mode: Pitch Pressure Selector Valve - Valve Fails in Intermediate Position 
FMEA Identifier: MS-SS-ACT-01-001 


Detected by -I Tests 


Sensor Identifier 

Sensor Description 

Test Name 

SEN 0004 

Pitch Pressure Selector Valve Position 

Selector Valve Intermediate Position 

SEN 0023 

Pitch LVDT Displacement Transducer 1 

No Position Change 

SEN 0024 

Pitch LVDT Displacement Transducer 2 

No Position Change 

SEN 0025 

Pitch LVDT Displacement Transducer 3 

No Position Change 


Figure 2. — ETA tool detectability report for the example diagnostic model. 
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5.2.2 Generation of the ETA Tool Test Utilization Report 
Syntax for generating a Test Utilization Report: 

» ETAT_v6_7.exe -T 

Special Input Requirements: 

None 

Output Report Description: 

The Test Utilization report generated for the example system provided in the software package is named: 

A ETATJHOME \ Basic_System_Test_Utilization_Report.htm 

The report can be either opened directly into an Internet browser or accessed by the “Test Utilization Report” link on 
the main output file, BasicJ5ystem_TestAnalysis_Main.htm. 

The Test Utilization report provides details regarding the ability of each test to detect system failure modes. This 
information provides justification for retaining a test and the associated sensor. As with any launch vehicle, during 
the design phase of NASA’s Ares I Project studies were continuously conducted to scrub down (i.e., remove 
unnecessary) sensors from the instrumentation suite. During these studies, system designers were required to 
demonstrate the usefulness of each sensor — this analysis could support that demonstration from the diagnostic 
perspective. 

The Test Utilization report generated by this command line option contains four sections that are separated by blue 
horizontal lines. The top section contains testability conditions for the analysis conducted by TEAMS. The TEAMS 
analysis date and time, as well as the diagnostic model are reported. This section also includes the TEAMS analysis 
options selected such as the technology labels, test labels and system modes. 

The second section displays a simple reminder notice to the user that the results presented here do not include tests 
that solely detect their own sensor failure modes. 

The third section contains metrics generated during the ETA Tool process relevant to the system’s test utilization 
analysis. The number of tests evaluated in this analysis, less the tests that provided detection solely for their own 
sensors failure mode, and the number of tests that provided no detection for the failure modes considered in the 
testability analysis are reported here. This section also lists the tests not utilized for detection in this analysis in a 
table format, providing the test name, corresponding sensor identifier and sensor description. 

In the last section, each test is presented, separated by a green horizontal line. For each test, the test name, 
corresponding sensor and sensor description are reported. In addition, a table containing all the failure modes 
detected by that test is also reported here. The tabulated data includes the failure mode name, the FMEA identifier, 
the name of the component from which the failure mode originated, and the criticality value assigned to the failure 
mode for the current phase of operation. 

Figure 3 illustrates the ETA Tool Test Utilization report for the example diagnostic model. 
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ETAT Analysis Summary - Test Utilization Report 

Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 
System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1R_Phase-B 
Crit-3_Phase-B 
Crit-1S_Phase-B 
Crit-1_Phase-B 
Test Labels: 

Effect 

Flight 


Note: For this report, tests that solely detect their own sensor fault are not reported 


Test Utilization Analysis 

Number of Tests =44 Number of Unused Tests =4 


Tests Not Utilized 


TestXame 

Sensorldentifier 

Sensor Description 

SelectorValve Primary- Position 

SEN0004 

Pitch Pressure Selector Valve Position 

SelectorValve Primary 7 Position 

SEN0006 

Yaw Pressure SelectorValve Position 

PSV Open 

SEN0005 

Yaw Propellant Supply Valve Positior 

PSV Open 

SEN0003 

Pitch Propellant Supply Valve Positio: 


(1 )Test SelectorValve Intermediate Position Sensor SEN0004 -Pitch Pressure SelectorValve Position 


Detected Failure Mode 


Failure Mode 

FMEA Identifier 

Component 

Criticality 

Valve Fails in Intermediate Positior 

MS-SS-ACT-01 -00 1 

Pitch Pressure SelectorValve 

1 



(2)Test SelectorValve Intermediate Position Sensor. SEN0006 -Yaw Pressure SelectorValve Position 


Figure 3. — ETA tool test Utilization report for the example diagnostic model. 
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5.2.3 Generation of the ETA Tool Failure Mode Isolation Report 
Syntax for generating a Failure Mode Isolation Report: 

» ETAT_v6_7.exe -I 

Special Input Requirements: 

None 


Output Report Description: 

The Failure Mode Isolation report generated for the example system provided in the software package is named; 

A ETATJHOME \ Basic_System_Failure_Mode_lsolation_Report.htm 

The report can be either opened directly into an Internet browser or accessed by the “Failure Mode Isolation Report” 
link on the main output file, Basic_System_TestAnalysis_Main.htm. 

The Failure Mode Isolation report provides information on the system’s ability to isolate each of the system’s failure 
modes. This analysis and reporting capability proved useful during the design phase of NASA’s Ares I Project for 
verifying the ability of subsystem designs to meet requirements for fault isolation. Here, failure mode isolation is the 
determination of the possible physical locations of a failure cause. 

This analysis is performed by grouping failure modes that have identical detection signatures. Groups that contain a 
single failure mode are considered to be isolated — meaning, that the system is able to uniquely identify that single 
failure mode based on the tests that it fails. Failure mode groups containing more than one failure mode are 
ambiguous. In other words, the system is unable to distinguish which failure mode or modes within the group may 
be occurring based on their detection signature. 

The Failure Mode Isolation report generated by this command line option contains four sections that are separated 
by blue horizontal lines. The top section contains testability conditions for the analysis conducted by TEAMS. The 
TEAMS analysis date and time, as well as the diagnostic model are reported. This section also includes the TEAMS 
analysis options selected such as the technology labels, test labels and system modes. 

The second section contains metrics generated during the ETA Tool process relevant to the system’s failure mode 
isolation analysis. This section reports the following metrics: 

• Number of Failure Mode Groups — the number of failure mode groups generated in this analysis for the 
number of active failure modes in the model 

• Number of Failure Modes — the number of failure modes that are active for the specified testability analysis 
conditions 


• Number of Isolated Groups — Failure mode groups containing a single failure mode 

• Maximum Failure Mode Group Size — The number of failure modes in the largest group 


• Calculated Ambiguity Score — a simple metric that allows comparison between system design changes with 
respect to the impact on failure mode isolation. The calculated ambiguity score represents the maximum 
number of tests required to fully isolate all the failure modes. This metric is the sum of each group’s failure 
mode population minus one, or in equation form. 


IL 

ambiguity score = 2> - « 
(=0 


where P, is the population of the / failure mode group and n is the number of failure mode groups. 


This second section also displays the population distribution of the failure mode groups, both in a text format and 
graphically. 

The third section displays a simple reminder notice to the user that the results presented in the final sections are the 
failure mode groups displayed in ascending population. 
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The final section of this report displays each failure mode group separated by a green horizontal line. The groups are 
presented in ascending population size. For each group, two tables are provided. The first table displays the 
detection signature information for the group, including the sensor identifier, sensor schematic identifier, sensor 
description and test name. The second table contains all the failure mode information for each failure mode 
contained in this group. If the higher level ‘Element’ and ‘System’ components are defined in this diagnostic model, 
then they are presented here in the table’s initial columns, otherwise those columns are removed. This table also 
reported the failure mode’s component, failure mode name, FMEA identifier and the criticality of the failure for the 
phase of operation under analysis, if available. 

Figures 4 and 5 illustrate the ETA Tool Failure Mode Isolation report, upper portion and lower portion respectively, 
for the example diagnostic model. 
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ETAT Analysis Summary - Failure Mode Isolation Report 

Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

System Modes: 

Phase-B 
Switches 

Phase-B 

Technology Labels: 

Crit-1 R_Phase-B 
Crit-3_Phase-B 
Crit-1 S_Phase-B 
Crit-1 _Phase-B 
Test Labels: 

Effect 
Flight 

Ambiguity Analysis 

Numbei of Failuie Mode Groups .... 

Ninnbei of Failuie Modes 

Numbei of Isolated Gioups 

Maximum Failuie Mode Group Size 
Calculated Ambiguity Score 

Ambiguity Disfiihution (Failuie Mode Level! 

Peiceutage of gioups with 1 memheis 
Peicentage of gioups with 2 memheis 
Peiceutage of gioups with 3 memheis 
Peicentage of gioups with 6 memheis 
Peiceutage of gioups with 10 memheis . 

Peicentage of gioups with 15 members . 


Failure Mode Ambiguity Distribution 


2 2 i 2 


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 


Number of Failure 
Mode Groups 
(61 Total) 


Group Size 


81 .97% (50 of 61 groups) 
6.56% ( 4 of 61 groups) 
3.28% ( 2 of 61 groups) 
3.28% ( 2 of 61 groups) 
1.64% ( 1 of 61 groups) 
3.28% ( 2 of 61 groups) 


61 
118 
.. 50 
15 
.55 


Figure 4. — ETA tool failure mode isolation report, upper portion, for the example diagnostic model. 
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Sensor 

Identifier 

Schematic 

Identifier 

Sensor Description 

Test 

SEN0011 

P13 

Pitch HydraulicSupplyPressure2 

Faulty SensorData 


System 

Component 

Failure Mode 

FMEA Identifier 

Criticality 

Vector Control System 

HydraulicSupplyPressure Sensor 

Faulty Sensor 

MS-SS-HYD-07-001 

IS 


Group Size 


=1 1 1 czzi 1 1 1 r- 

6 7 8 9 10 11 12 13 14 15 


Note: For this report, the failure mode groups presented below are in order of the failure mode population in the group 


Failure Mode Group #1 


Detection Signature; 1 Tests 


Failure Mode Group contains 1 Failure Mode(s) 


Failure Mode Group #2 


Detection Signature: 1 Tests 


Sensor 

Identifier 

Schematic 

Identifier 

Sensor Description 

Test 

SEN0030 

Lv2 

Pitch Hydraulic Reservoir Level Sensor 2 

Faulty SensorData 


Failure Mode Group contains 1 Failure Mode(s) 


System 

Component 

Failure Mode 

FMEA Identifier 

Criticality 

Vector Control System 

Hydraulic Reservoir Level Sensor 

Faulty Sensor 

MS-SS-HYD-0 8-001 

IS 


Failure Mode Group #3 


Detection Signature 1 Tests 


Sensor 

Identifier 

Schematic 

Identifier 

Sensor Description 

Test 


Figure 5. — ETA tool failure mode isolation report, lower portion, for the example diagnostic model. 
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5.2.4 Generation of the ETA Tool Component Isolation Report 
Syntax for generating a Component Isolation Report: 

» ETAT_v6_7.exe -iso <Component Label> 

where <Component Label> is selected from the set of TEAMS module labels assigned for the current diagnostic 
model. 

Special Input Requirements: 

The component label input on the command line must be a hierarchical label assigned within the diagnostic model. 

If a component label is entered on the command line that is not in the diagnostic model, the ETA Tool will notify the 
user and discontinue processing. Also a basic assumption for component isolation analysis is that the designated 
components cannot be nested, meaning that a designated component cannot contain another designated component. 
If a nested designated component is uncovered by the ETA Tool during processing, the tool will report the discovery 
and discontinue processing. 

Within the example diagnostic model, the following component labels are used; System, Assembly, LRU, 
Component, Sensor and Failure mode. The Component Isolation analysis works for each label, except for two. The 
‘Failure mode’ label, which is essentially the Failure Mode Isolation analysis. And the ‘System’ label because the 
highest level module in TEAMS Designer is by default assigned the ‘System’ hierarchical label and therefore 
creates a nested designated component situation. 

Output Report Description: 

The Component Isolation report generated for the example system provided in the software package is named: 

A ETAT_HOME \ Basic_System_<Component Label>_lsolation_Report.htm 

where <Component Label> is provided by the user on the command line. The report can be either opened directly 
into an Internet browser or accessed by the “Component Isolation Report” link on the main output fde, 
Basic_System_TestAnalysis_Main.htm. 

The Component Isolation report provides information regarding the system’s ability to isolate failures to a specific 
component within the system. From a maintenance perspective it may not be imperative to identify the exact failure 
mode, but rather to identify the component where the failure occurred. For the Ares I project, launch pad logistics 
and maintainability personnel required that components identified as line replaceable units — meaning they were 
intended to be replaced on the launch pad — contained only failure modes that could be isolated to that component. 

For the Component Isolation report, the user provides the label of the components within the diagnostic model to 
which failure modes are to be isolated. As with the failure mode isolation analysis, failure modes are grouped by 
detection signatures. Here, the failure mode groups are further divided into physical components where the failure 
originates. The depth to which failure mode components are derived is determined by the user-selected isolation 
level. The output report is similar in format to that generated by the Failure Mode Isolation Report, except the 
diagnostic metrics are relative to the components identified for isolation. 

The Component Isolation report (Figs. 6 and 7) generated by this command line option contains four sections that 
are separated by blue horizontal lines. The top section contains testability conditions for the analysis conducted by 
TEAMS. The TEAMS analysis date and time, as well as the diagnostic model are reported. This section also 
includes the TEAMS analysis options selected such as the technology labels, test labels and system modes. 

The second section contains metrics generated during the ETA Tool process relevant to the system’s component 
isolation analysis. Note that, for this analysis, failure mode groups that contain no failure modes from model 
components labeled with the same label specified on the command line option are not included in the final analysis. 
This section reports the following metrics: 

• Number of Failure Mode Groups — the number of groups generated in this analysis for the number of active 
components in the model 

• Number of Active Components — the number of components that have failure modes that are part of the 
testability analysis 
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• Number of Active Non-Components — the number of non-components that have failure modes that are part 
of the testability analysis 

• Number of Isolated Groups — failure mode groups containing a single component or non-component 


• Maximum Failure Mode Group Size — the number of components and non-components in the largest group 


• Calculated Ambiguity Score — a simple metric that attempts to provide a tool for comparison with system 
design change impacts on component isolation. This metric is simply the sum of each group’s component 
and non-component population minus one, or in equation form. 


ambiguity score — 2>< - « 
1= 0 


where P, is the population of the ; th failure mode group and n is the number of failure mode groups. 


This second section also displays the population distribution of the failure mode groups, both in a text format and 
graphically. 


The third section is the component isolation summary for this analysis. This includes a listing of the number of 
isolated components and a hypertext link to a detailed isolation assessment report for all the components analyzed. 
This detailed report will be discussed later in this section. 


The final section of this report displays each failure mode group separated by a green horizontal line. The groups are 
presented by ascending population size. For each failure mode group, multiple tables are provided. The first table 
displays the detection signature information for the group, including the sensor identifier, sensor schematic 
identifier, sensor description and test name. For each component or non-component member of the group, a table is 
presented containing the failure mode’s component, failure mode name, FMEA identifier and the criticality of the 
failure for the phase of operation under analysis, if available, for each failure mode associated with that component. 


Figures 6 and 7 illustrate the ETA Tool Component LRU Isolation report, upper portion and lower portion 
respectively, for the example diagnostic model. To generate this report, the user should specify “LRU” as the 
component label. 
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ETAT Analysis Summary - Component Isolation Report 

Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1 R_Phase-B 
Crit-3_Phase-B 
Crit-1 S_Phase-B 
Crit-1 _Phase-B 

Test Labels: 

Effect 

Flight 


Ambiguity Analysis (for Components labeled as "LRU") 

Number of Failure Mode Groups (for LRU analysis) 8 

Number of Active LRUs 2 

Number of Active Non-LRUs 74 

Number of Isolated Groups 4 

Maximum Failure Mode Group Size 15 

Calculated Ambiguity Score 30 


Ambiguity Distribution (LRU Level) 

Percentage of groups with 1 members 50.00% (4 of 8 groups) 

Percentage of groups with 2 members 25.00% (2 of 8 groups) 

Percentage of groups with 15 members 25.00% (2 of 8 groups) 


LRU Ambiguity Distribution 



Group Size 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 


Figure 6. — ETA tool component isolation report, upper portion, for the example diagnostic model where the selected 
designated component label was ‘LRU’. 
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LRU Isolation Summary 0 LRUs are isolated". 

{Note "Isolated" means that all the component's active failure modes are detected and isolated to an ambiguity group that contains only failure 
modes from this component } 

LRU Isolation Assessment Table 

Failure Mode Group #51 - 1 LRU-Designated and 0 non-LRU-Designated members 

Detection Signature: 1 Tests 


Sensor 

Identifier 

Schematic 

Identifier 

Sensor Description 

Test 

SEN0002 

SS2 

Yaw Turbine Speed Sensor 

Faulty Sensor Data 


Failure Mode Group Members 

1 . LRU: Yaw Hydraulic Pump Assembly (Schematic ID: None) 

Associated 1 Failure Models ) 


Component 

Failure Mode 

FMEA Identifier 

Criticality 

Shaft Speed Sensor 

Faulty Sensor 

MS-SS-HPump-08-00 1 

IS 


Failure Mode Group #52 - 1 LRU Designated and 0 non-LRU Designated members 

Detection Signature : 4 Tests 


Sensor 

Identifier 

Schematic 

Identifier 

Sensor Description 

Test 

SEN0002 

SS2 

Yaw Turbine Speed Sensor 

No Rotation 

SEN0006 

PV22 

Yaw Pressure Selector Valve Position 

Selector Valve Secondary Position 

SEN0013 

P22 

Y aw Hydraulic Supply Pressure 1 

Low Hydraulic Pressure 

SEN0014 

P23 

Yaw Hydraulic Supply Pressure 2 

Low Hydraulic Pressure 


Failure Mode Group Members 

1 . LRU: Yaw Hydraulic Pump Assembly (Schematic ID: None) 

Associated 1 Failure Mode(s) 


Component 

Failure Mode 

FMEA Identifier 

Criticality 

Hydraulic Turbine 

Turbine Fails to Function 

MS-SS-HPump-0 1-001 

1R 


Figure 7. — ETA Tool Component Isolation report, lower portion, for the example diagnostic model where the selected 
designated component label was ‘LRU’. 
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The detailed component isolation assessment table is presented in a separate report that is hypertext linked to the 
Component Isolation report. Figure 8 illustrates this table report. The report reiterates the testability analysis 
conditions and pertinent ambiguity analysis metrics; 


• Number of Active Components — the number of components that have failure modes that are part of the 
testability analysis 

• Number of Active Non-Components — the number of non-components that have failure modes that are part 
of the testability analysis 

• Number of Failure Mode Groups — the number of groups generated in this analysis for the number of active 
components in the model 

• Number of Isolated Groups — failure mode groups containing a single component or non-component 

• Number of Isolated Components — components that belong solely to isolated groups 

The table then presents for each component analyzed, the component’s name, the number of active failure modes 
contained in the component, the number of groups containing those failure modes; then for each failure mode: the 
group identifier containing that failure mode, failure mode name and the Detection/Isolation status assigned to the 
failure mode. The Detection/Isolation status is either ‘Not Detected’, ‘Not Isolated’ or ‘Isolated’. If the failure mode 
is not detected, then it is highlighted in red in the table. If the failure mode is isolated, then it is highlighted in green. 
The intention of the table is to provide a visual summary of the isolation assessment with respect to the components. 
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ETAT Analysis Summary - LRU Isolation Assessment Table 

Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1 R_Phase-B 
Crit-3_Phase-B 
Crit-1 S_Phase-B 
Crit-1 _Phase-B 

Test Labels: 

Effect 

Flight 


Ambiguity Summary Stats 

Number of Active LRUs 2 

Number of Active Non-LRUs 74 

Number of Failure Mode Groups with LRU members 8 

Number of Isolated Groups 4 

Number of Isolated LRUs 0 


LRU Ambiguity Output 


LRU Name 

Number of 
Failure 
Modes 

Number of 
Failure Mode 
Groups 

Failure Mode 
Group 
Identifier 

Failure Mode 

Detection 

Isolation 

Status 

Y aw-Hydraulic-Pump-Assembly 

5 

4 

38 

Pump Fails to Function 

Not Isolated 

40 

Hydraulic Leak 

Not Isolated 

51 

Faulty Sensor 

Isolated 

52 

Tuibine Fails to Function 

Isolated 


N/A 

Propellant Leak 

Not Detected 

Pitch-Hydraulic-Pump-Assembly 

5 

4 

45 

Pump Fails to Function 

Not Isolated 

47 

Hydraulic Leak 

Not Isolated 

56 

Faulty Sensor 

Isolated 

57 

Tuibine Fails to Function 

Isolated 


N/A 

Propellant Leak 

Not Detected 


Figure 8. — ETA Tool Component Isolation Assessment Table report for the example diagnostic model where the 
selected designated component label was ‘LRU’. 
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5.2.5 Generation of the ETA Tool Effect Mapping Report 
Syntax for generating an Effect Mapping Report: 

» ETAT_v6_7.exe -E 

Special Input Requirements: 

Within the model, certain tests must be established with a naming convention that identifies it as an effect test rather 
than a sensor detection test. For example an effect test could be a “loss of functional redundancy”, where a sensor 
test would be “loss of fluid pressure”; even though they may both detect the same functional effect. The distinction 
is subtle, but this analysis allows the establishment of system level effects that can be analyzed simultaneously with 
the sensor testability analysis. 

The naming convention for an effect test in the TEAMS diagnostic model is, 

<Effect Description>_Effect, 
for example, “Loss-of-Redundancy_Effect”. 

Output Report Description: 

The Effect Mapping report generated for the example system provided in the software package is named: 

A ETATJHOME \ Basic_System_Effect_Report.htm 

The report can be either opened directly into an Internet browser or accessed by the “Effect Mapping Report” link 
on the main output file, Basic_System_TestAnalysis_Main.htm. 

For the Effect Mapping analysis the software utilizes the established naming conventions to distinguish between 
modeled tests attributed directly to physical sensors and tests that were intended to represent system-level 
conditions. An example of the latter test implementation would be a system condition representing the loss of 
redundancy due to loss of component function. Whether or not there was a physical sensor that could measure the 
effect, a pseudo sensor test point could be modeled that contained this system-level effect test. By taking advantage 
of this capability, the ETA Tool can combine a testability analysis that is conducted with physical sensor 
measurements and an effects analysis that within TEAMS Designer could only be applied to effect nodes. The 
combined analysis provided the mapping of failure modes to system level effects, while at the same time providing 
detection signatures aligned to those system level effects. This level of analysis was utilized by Ares I vehicle 
integration systems engineers responsible with the vehicle level loss of mission analysis and probability risk 
assessment. 

The analysis performed by this option creates an Effect Mapping Report that provides the summary analysis 
information along with hyper text links to three analysis reports: a detectability report and two ambiguity reports for 
the active failure modes relative to the system effects. Figure 9 illustrates the summary information report for the 
effects analysis. The top section contains testability conditions for the analysis conducted by TEAMS. The TEAMS 
analysis date and time, as well as the diagnostic model are reported. This section also includes the TEAMS analysis 
options selected such as the technology labels, test labels and system modes. 
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ETAT Analysis Summary - Effect Mapping Report 
Model Version: Basic_System 

Testability Run Date: Mon Jan 03 15:41:12 2011 
Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

System Modes: 

Phase-B 
Switches 
Phase-B 
Technology Labels: 

Crit-1R_Phase-B 

Crit-3_Phase-B 

Crit-1S_Phase-B 

Crit-1_Phase-B 

Test Labels: 

Effect 

Flight 


Failure Mode Mapping to System Effects Analysis 

Number of Effects = 5 

Effects Not Mapped (1) 

* Effect: Fire 

Failure Modes Not Mapped: (105) 

(Failure Modes not mapped to an Effect Test) 

Effects Analysis Output Reports 

Effect Mapping Report 

System Effect Ambiguity Report - Basic Format 
System Effect Ambiguity Report - Detailed Format 


Figure 9. — ETA tool effect mapping main report for the example diagnostic model. 
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The second section contains the following summary information specific to the effect mapping analysis; 

• Number of Effects — this is the number of effects available from the current testability analysis 

• Effects Not Mapped — this is a list of effects that did not have a failure modes mapped to them 

• Failure Modes Not Mapped — this is a list of failure modes that did not map to an effect. If this list is 
greater than ten, then a hyperlinked document will display the list. 

This section also contains the three hyperlinked reports: the Effect Mapping Report, the System Effect Ambiguity 
Report (Basic Format) and the System Effect Ambiguity Report (Detailed Format). 

The Effect Mapping Report is displayed in Figure 10 and contains two sections divided by a blue horizontal line. 
The top section repeats the testability conditions information for the analysis conducted by TEAMS. The second 
section reports the failure modes that result in the individual system effects, grouped by the system effects. Each 
system effect is presented separated by a green horizontal line. For each system effect, the report presents a table of 
the failure modes that contains the following information from the diagnostic model; the failure mode name, failure 
mode identifier and the component where the failure originated. 


NASA/CR— 20 11-21 7240 


25 



ETAT Analysis Summary - Failure-Mode-to-System-Effect Mapping Report 

Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:49:18 2011 

Test Conditions 

TEAMS Model Analyzed 

Basic_System ( within BasicjSystem) 

System Modes; 

Phase-B 

Switches 

Phase-B 

Technology Labels; 

Crit-1R_Phase-B 
Crit-3_Phase-B 
Crit-1S_Phase-B 
Crit-1_Phase-B 
Test Labels; 

Effect 

Flight 


(1 ) Effect Pitch Actuator Lockup 


4 Mapped Failure Modes 


Failure Mode 

FMEA Identifier 

Component 

Loss of Communication with Avionic 

EXT-AV-001 

Avionics 

Erroneous NULL Pitch Command 

EXT-AV-002 

Avionics 

Stuck In NULL Position 

MS-SS- ACT -02-002 

Power Valve 

Actuator Locked In Place 

MS-SS-ACT -03-00 1 

Pitch Actuator 


(2) Effect Pitch Actuator Hard over 


3 Mapped Failure Modes 


Failure Mode 

FMEA Identifier 

Component 

Erroneous Full Extend Pitch Command 

EXT-AV-004 

Avionics 

Stuck In An Operating Position 

MS-SS-ACT -02-00 1 

Power Valve 





Figure 10. — ETA tool effect mapping report for the example diagnostic model. 
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The last two hyperlinked reports linked on the Effects Mapping main page, provide details about the ambiguity 
analysis performed from these testability results. The first report. System Effect Ambiguity Report (Basic Format), 
provides the ambiguity analysis with respect to the system effects in a basic format, shown in Figure 11. The report 
contains two sections separated by a blue horizontal line. The top section reiterates the testability analysis 
conditions. The bottom section is further subdivided by green horizontal lines for each failure mode grouping in the 
analysis. For each group, two tables are reported. The first table lists the system effects that define the detection 
signature for the group and the second table reports for each failure mode contained in this group; the element, 
system and component of the failure mode, if they are assigned within the diagnostic model, the failure mode name, 
failure mode identifier and the assigned criticality. 
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Ambiguity Assessment Report - Effect Failure Mode Groups - Basic Format 

Model Version: Basic_System 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed: 

Basic_System 

System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1 R_Phase-B 
Crit-3_Phase-B 
Crit-1 S_Phase-B 
Crit-1 _Phase-B 

Test Labels: 

Effect 

Flight 


Failure Mode Group #5 


System Subsystem Level Effects Mapped: 2 Effect(s) 


Effect Name 


Pitch Actuator Lockup 


Yaw Actuator Lockup 


Failure Mode Group contains 1 Failure Mode(s) 


System 

Component 

Failure Mode 

FMEA Identifier 

Criticality 

Not Found 

Avionics 

Loss of Communication with Avionics 

External 

i 


Failure Mode Group #1 

System Subsystem Level Effects Mapped: 1 Effect(s) 


Effect Name 


Y aw Actuator Handover 


Failure Mode Group contains 3 Failure Mode(s) 


System 

Component 

Failure Mode 

FMEA Identifier 

Criticality 

Not Found 

Avionics 

Erroneous Full Extend Yaw Command 

External 

i 

Vector Control System 

Power Valve 

Stuck In An Operating Position 

MS-SS-ACT-02-001 

i 

Vector Control System 

Yaw Actuator 

Actuator Detaches 

MS-SS-ACT-03-003 

i 


Figure 1 1 . — ETA tool effect ambiguity report in the basic format for the example diagnostic model. 
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The second system effect ambiguity report presents additional information about the failure modes contained within 
the groups. This report is only useful if the available sensor tests are also included in the testability analysis 
performed in TEAM Designer. Figure 12 shows the breakdown of the report. In this report, for each failure mode 
group a single table is generated with the following columns; 

• Element — the element module as defined in the diagnostic model from which the failure mode originates. 
If there are no element modules defined, then this column is removed. 

• System — the system module as defined in the diagnostic model from which the failure mode originates. If 
no system modules are defined, then this column is removed. 

• Component — the module from which the failure mode originates. 

• Failure Mode 

• FMEA Identifier 

• Criticality — the criticality assigned to the failure mode in the diagnostic model for the current testability 
conditions 

• Outcomes — The system effects which define this failure mode group 

• Test Sensors — The sensor tests which detect this failure mode. The sensor information includes the sensor 
identifier and sensor name 

• Initial Failure Effects — The column reports the physical failure effects propagated by this failure mode. 
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Ambiguity Assessment Report - Effect Failure Mode Groups - Detailed Format 
Model Version: Basic_System 

Testability Run Date: Mon Jan 03 15:41:12 201 1 
Test Conditions 

TEAM S Model Analyzed: 

Basic_System 
System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1 R_Phase-B 
Oit-3_Phase-B 
Crit-1 S_Phase-B 
Crit-1 _Phase-B 
Test Labels: 

Effect 

Flight 


Failure Mode Group #6 


System/Subsystem Level Effects Mapped: 2 Effect(s)and 1 Failure Mode(s) 


System 

Component 

Failure Mode 

FMEA 

Identifier 

Criticality 

Outcome 

Test SensorO) 

\SemieflD (Dezsripnc*i\ 

Initial 

Failure 

Effects 

Not 

Found 

Avionics 

Loss ofCocrj3iur.icatior. 
with Avionics 

Extar.il 

i 

♦Pitch 
Actuator 
Lockup 
♦ Yarv 
Actuator 
Lockup 

♦ SENOO 16 (Pitch Actuator 
P ower Valvt Solenoid A 
Currant) 

* SENOO 17 (Pitdl Actuator 
Power Valve Solenoid B 
Currant) 

* SEN9O20 (Yaw Actuator 
Power Valve SolaioitJB 
Cutrar.t) 

* SENOO 19 (Yaw Actuator 
Power Valve Solenoid A 
Currant) 

♦ SENOO 13 (Pitch LVDT 
Displacement Transducer 1 ) 

* SEN0024 (Pitch LVDT 
Displacement Transducer 2 ) 

♦SEN0025 (Pitch LVDT 
Displacement Transducer 3 ) 

♦ SEN0026 (Yaw LVDT 
Displacement Transducer 1 ) 

♦SEN0027 (Yaw LVDT 
Displacement Transducer 2 ) 

♦ SEN002 8 (Yaw LVDT 
Displacement Transducer 3 ) 

* No Currant 

* No Position 
Change 


Figure 12 . — ETA tool effect ambiguity report in the detailed format for the example diagnostic model. 
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5.2.6 Generation of the ETA Tool Sensor Sensitivity Report 
Syntax for Generating a Sensor Sensitivity Report: 

» ETAT_v6_7.exe -si <sensor sensitivity file> 

Special Input Requirements: 

Sensor Sensitivity input file. The format of this file is presented in section Installation and Setup. 

Output Report Description: 

Three reports are generated for the example system provided in the software package: 

A ETATJHOME \ Basic_System_Sensor_Sensitivity_Report-Sensor_Level.htm 

A ETATJHOME \ Basic_System_Sensor_Sensitivity_Report-Measurement_Level.htm 

A ETATJHOME \ Basic_System_Sensor_Sensitivity_Report-Measurement_Group_Level.htm 

These reports can be either opened directly into an Internet browser or accessed by the “Sensor Sensitivity Analysis 
by Individual Sensors”, “Sensor Sensitivity Analysis by Measurements” and “Sensor Sensitivity Analysis by 
Measurement Groups” links, respectively, on the main output file, Basic_System_TestAnalysis_Main.htm. 

The sensor sensitivity analysis was created to assess the impact of the removal of individual sensors or groups of 
sensors on the system’s diagnostic capabilities. The analysis can facilitate various design studies to determine the 
importance of measurements and tests, as well as diagnostic strategies to overcome sensor signal loss. 

The analysis currently performs three distinct cycles where individual and groups of sensors can be systematically 
removed. The definition of the sensors and groups of sensors to be removed for each cycle is defined in an external 
input file supplied by the user on the command line. 

Prior to the sensor sensitivity analysis, the failure modes are reviewed to determine if they are failure modes of the 
sensors or of the general system. Sensor failure modes are removed from consideration during the analysis and the 
remaining failure modes are used to establish a set of baseline diagnostic metrics for the system. Changes to the 
diagnostic capability of the system are made relative to these baseline metrics. This ensures that sensor-related 
failure modes do not bias the diagnostic evaluation. For example, given a sensor ‘X’ has two inherent failure modes, 
the simple removal of the sensor will eliminate two failure modes from the system being evaluated, unfairly biasing 
the analysis in a positive direction if the failure modes have not been filtered out. 

One caveat to this aspect of the analysis is that sensor failures that are essentially system failure modes do remain in 
the baseline and therefore are removed when the sensor is removed. For example, a sensor can have two failure 
modes: one failure mode is a sensor signal fault and the other failure mode is a fluid leak at the insertion point of the 
duct. The former failure mode is removed from the baseline metrics, but the latter remains because the fluid leakage 
is a system failure mode caused by the physical presence of the sensor. 

The sensor sensitivity analysis option produces three reports. Each report has a similar format. The first report 
displays the impact on the system’s diagnostic capabilities (failure mode detection and isolation) with the loss of 
each sensor individually. The second report, again displays the impact of the system’s diagnostic capability, but this 
time with sensors being removed by hardware redundancy groups. The third report looks at the impact on system 
diagnostic capability with the removal of the sensor across the entire system. 

Figures 13, 14, and 15 display each of the reports, respectively. Each report has four sections divided by a blue 
horizontal line. The top section in each reiterates the testability analysis conditions. The second section reports the 
following sensitivity analysis metrics; 

• Number of Tests — the number of available tests that are part of the testability analysis 

• Number of Active Sensors — Number of sensors with at least on active test 

• Active Sensors that provide zero contribution — Active sensors that provide no detection for the failure 
modes in this analysis 

• Number of Failure Modes — the number of failure modes that are part of the testability analysis 
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• Number of failure modes involving only sensor signal faults — failure modes that are only related to the 
sensor signal failure. 

• Overall Detection Coverage — a calculated metric that is equal to the number of detected failure modes 
divided by the total number of failure modes 

• Overall Detection Coverage w/o Sensor Faults — the Overall Detection Coverage metric with sensor signal 
failure modes removed from both the number of detected failure modes in the numerator and the total 
number of failure modes in the denominator. 


In this analysis, these metrics provide a baseline from which the impact values can be compared. 

The third section in each of the three reports provides a reminder statement about the current analysis process. 

Note: For this report, tests that solely detect their own sensor fault, and failure modes that result in sensor faidt are 
not used in the analysis. The faidt detection coverage and the failure mode groupings are recomputed with the 
removal of all sensor-fault-only tests and failure modes. 

Re-stating this notice, the sensor sensitivity analysis excludes failure modes that are the sensor signal faults and the 
tests that detect those sensor signal faults exclusively. The reason is that these will unduly bias the results. If a 
sensor is to be considered for inclusion in the diagnostic system it must detect more than just its own failure modes. 

The final section in each report provides a table of the diagnostic impacts due to the removal of the sensor or 
sensors. The following columns are reported in the table for the Sensor Level report; 

• Sensor Removed — the sensor identifier 


• Sensor Description 

• Removed Sensor-Related failure Modes — These are the failure modes that are removed from the analysis 
process because they are caused by faults in the sensor under consideration 

• Detection Coverage Loss | Coverage Percentage — the change in the system’s overall detection coverage if 
the sensor-related failure modes were not present in the baseline value 

• Detection Coverage Loss | Failure Modes Undetected — failure modes that are now undetected as a result of 
the removal of the sensor 


• Fault Isolation Loss | Change in Number of Failure Mode Groups — the total number failure mode groups 
lost or gained as a result of the removal of the sensor. The baseline groups are generated with the removal 
of the faults from the sensor under study. 

• Fault Isolation Loss | Change in Number of Isolated Failure Modes — the number of isolated failure modes 
lost or gained as a result of the removal of the sensor. The baseline groups are generated with the removal 
of the faults from the sensor under study. 

• Fault Isolation Loss | Ambiguity Score Change — the change in the ambiguity score compared to baseline 
score. The baseline ambiguity score is generated with the removal of the faults from the sensor under study. 

The final section tables in the reports for the Measurement Level and the Measurement Group Level are similar to 
the one described for the Sensor Level report except the initial column shows the Measurement or Group removed, 
respectively, and the following column consolidates the sensor identifier and description information for the sensors 
removed. 
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Sensor Sensitivity Analysis Summary - Sensor Level 
Model Version: BasicSystem 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed 
Basic_System 
System Modes: 

Phase-6 

Switches 

Phase-B 

Technology Labels: 

Crit-1R_Phase-B 
Crit-3_Phase-B 
Crit-1S_Phase-B 
Crit-1_Phase-B 
Test Labels: 

Effect 

Flight 


Note: For this report, tests that solely detect their own sensor fault and failure modes that result 
in sensor fault are not used in the analysis The fault detection coverage and the failure mode 
groupings are recomputed with the removal of all sensor fault only tests and failure modes 


Sensor Sensitivity An alysis 

NumberofTests 76 

Numberof Sensors- 32 

Sensors that provide no contribution 0 

Number of Failure Modes- 118 

Numberof Undetected Failure Modes 2 

Overall Detection Coverage 98.31% 

Numberof Failure Modes excluding sensor signal faults 86 

Overall Detection Coverage w/o Sensorfaults 97.67% 


Diagnostic Impact of Sensor Loss 


S«uor 

Removed 

Sensor 

Description 

Removed 

Sensor- 

Related 

Failure 

Modes 

X-VC4JS- 

Dttntgrion-'. 

Diagnostic C overage Loss 

Fault Isolation Loss 

Coverage 

Percentage 

Failure 

Modes 

Undetected 

/.ULt W - 

Ta'.'jr 

ArjnQvgMI-; 

Change in 
Number of 
Failure Mode 
Groups 

Change in 
Number of 
Isolated 
Failure Modes 

Ambiguity 

Score 

Change 

SEN0001 

Pitch Twbine 
Speed Sensor 

None 

No Change 

None 

-1 

-1 

+1 

SEN0W2 

Yaw Turbine 
Speed Sensor 

None 

No Change 

Nor.e 

-1 

-1 

+1 


Figure 1 3. — ETA tool sensor sensitivity analysis report for individual sensors for the example 
diagnostic model. 
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Sensor Sensitivity Analysis Summary - Measurement Level 

Model Version: Basic_System 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed 

Basic_System 
System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1R_Phase-8 
Crit-3_Phase-B 
Crit-1S_Phase-B 
Crit-1_Phase-B 
Test Labels: 

Effect 

Flight 


Note: For this report, tests that solely detect their own sensnrSai ill. anifrailure modes that result in sensor fault are not used in the analysis 
The fault detection coverage and the failure mode groupings are re computed with the removal of ait sensor fault only tests and failure modes 


Sensor Sensitivity Analysis 

NumberofTests 76 

Number of Sensors 32 

Sensors that provide no contribution 0 

Number of Failure Modes 118 

Number of Undetected Failure Modes 2 

Overall Detection Coverage— 98 31% 

Number of Failure Modes excluding sensor signal faults 86 

Overall Detection Coverage w/o Sensorfaults 97.67% 


Diagnostic Impact of Measurement Loss 


Measurement 

Removed 

Sensor(s) 

Removed 

Atm j» a - Siw DtXTtjrtM 

Removed 
Sensor-Related 
Failure Modes 

SME* a - -Ts:m 

Diagnostic Coverage Loss 

Fanlt Isolation Loss 

Coverage 

Percentage 

Failure Modes 
Undetected 

'SMEa a ■ TH.-J* 

Change in 
Number of 
Failure Mode 
Groups 

Change in 
Number of 
Isolated 
Failure Modes 

Ambiguity 

Score 

Change 

Pitch Hydraulic Supply 
Pleasure 

* SEN0010 - Pitch Hydraulic 
Supply Pressure 1 

• SENOOl 1 - Pitch Hydraulic 
Supply Pressure 2 

• MS-SS-HYD-0~-002 - 
(Hvdraulic Fluid Leak) 

* MS-SS-HYD-07-002 - 
(Hydraulic Fluid Leak) 

No Change 

None 

-1 

None 

+1 

Yaw Hydraulic Supply 
Pressure 

• SENOOl 3 - Yaw Hydraulic 
Supply Pressure 1 

♦ SENOOl 4 - Yaw Hydraulic 
Supply Pressure 2 

♦MS-SS-HYD-0--002- 
(Hydraulic Fluid Leak) 
* MS-SS-HYD-0~-002 - 
(Hydraulic Fluid Leak) 

No Change 

None 

-1 

None 

+1 


Figure 14. — ETA tool sensor sensitivity analysis report for hardware redundant sensors for the example diagnostic 
model. 
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Sensor Sensitivity Analysis Summary - Measurement Group Level 

Model Version: Baslc_System 

Testability Run Date: Mon Jan 03 15:41:12 2011 

Test Conditions 

TEAMS Model Analyzed; 

Basic_System 
System Modes: 

Phase-B 

Switches 

Phase-B 

Technology Labels: 

Crit-1R_Phase-B 

Crit-3_Phase-B 

Crit-1S_Phase-B 

Crit-1_Phase-B 

TestLabels: 

Effect 

Flight 


Note: For this report, tests that solely detect their own sensorfauhand failure modes that result in sensor fault are not used in the analysis 
The fault detection coverage and the failure mode groupings are re computed with the removal of all sensor fault only tests and failure modes 


Sensor Sensitivity Analysis 

NumberofTests. 76 

Number of Sensors. 32 

Sensors that provide no contribution 0 

MnmhprnfFaili.ro Wnrlne 118 

Numberof Undetected Failure Modes ......... 2 

Overall Detection Coverage 98.31% 

Number of Failure Modes excluding sensor signal faults 86 

Overall Detection Coverage w/o Sensorfaults 97.67% 


Diagnostic Impact of Measurement Group Loss 





Diagnostic Coverage Loss 

Fault Isolation Loss 


Group 

Removed 

Sensor(s) 
Removed 
a - Smar 

Sensor-Related 
Failure Modes 

Smla 

Coverage 

Percentage 

Failure Modes 
Undetected 

XME* JZ> - rTjtow* 

Change in 
Number of 
Failure Mode 
Groups 

Change in 
Number of 
Isolated 
Failure Modes 

Ambiguity 

Score 

Change 


Turbine Speed Sensor 

* SEN0001 - Pitch Turbine 
Speed Sensor 

* SEN0002 - Yaw Turbine 
Speed Sensor 

None 

No Change 

None 


-1 

+ 2 


Propellant Supply 

♦ SEN0003 - Pitch Propellant 
Supply Valve Position 

None 



_2 

-1 



Valve Position 

* SEN0005 - Yaw Propellant 
Supply Valve Position 







Figure 15. — ETA tool sensor sensitivity analysis report for common sensors across the system for the example 
diagnostic model. 
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5.3 Related Processing 

During the ETA Tool processing, the software will attempt to copy specific required files from the TEAMS model 
directory to the directory containing the ETA Tool executable. In addition, the ETA Tool will convert the TEAMS 
Designer Testability output D-Matrix from the Microsoft Excel format to a comma-separated-variable formatted 
file. It is recommended that the user close all Excel files prior to operating the ETA Tool program. 

5.4 Messages 

The following error messages and exit codes are generated by the ETA Tool; 


Error code 

Message 

-98 

Unable to open the standard log file 

-99 

Unable to open the debug log file 

-101 

No arguments entered on the command line 

-102 

Only Command line argument entered was a debugging option 

-103 

No valid command line inputs found 

-104 

The auto-setup could not be performed because the environmental variable is not established for TEAMS 
model location. 

-201 

Unable to locate the TEAMS model file. 

-202 

More than one TEAMS model file available in the TEAMS directory. Unable to determine which model to 
select. 

-203 

No TEAMS model in the TEAMS directory 

-204 

Unable to locate the TEAMS testability options file which should be in the REPORTS directory. 

-205 

Unable to locate the TEAMS model hierarchical file which should be in the REPORTS directory. 

-206 

Unable to obtain a listing of the REPORTS directory. 

-207 

Unable to find a Testability output directory in the REPORTS directory. 

-208 

Unable to locate the testability D-Matrix which should be in the REPORTS directory. 

-209 

Unable to convert the EXCEL fonnatted D-Matrix into a CSV format file. 

-210 

Unable to open <filename>, the D-Matrix file. 

-211 

Unable to locate the TEAMS testability ambiguity-dynamic file which should be in the REPORTS 
directory. 

-212 

Unable to locate the TEAMS testability failure-detection-isolation file which should be in the REPORTS 
directory. 

-213 

Unable to locate the TEAMS testability figures-of-merit file which should be in the REPORTS directory. 


NASA/CR— 20 11-21 7240 


36 




Error code 

Message 

-214 

Unable to open the TEAMS Designer Analysis Options file (<filename>). 

-215 

Unable to open the TEAMS hierarchical file (<filename>). 

-216 

Unable to open the TEAMS testability figures-of-merit file (<filename>). 

-301 

No components were located in the model labeled with the name specified for the component isolation 
analysis. 

-302 

Problem in the process of assigning the submodules to this module (<module name>). The number of 
submodules assigned in the first pass was <count 1> and the second pass was <count 2>. 

-303 

Unable to open the Instrumentation Listing file (<filename>). 

-304 

Unable to open the Sensitivity Instrumentation Listing file (<filename>). 

-305 

Unable to locate the MTTF string in the header of the D-Matrix file. Therefore the format is not what is 
expected. 

-306 

Unable to locate the MTTF string in the header of the D-Matrix file after rewinding the file. 

-307 

TEST <test name> was not properly assigned to either a sensor test or an effect test. 

-308 

No effects were detected in the model, so the failure mode mapping to effects report cannot be generated. 

-309 

There are <count> failure modes found within nested components selected for isolation. Need to fix the 
nested components reported. 

-310 

Unable to assign the following active failure mode - <failure mode> to either the component to be isolated 
(<isolated component label>) or to one of the currently recognized component label designations of 
“Sensor”, “RBD”, “Subsystem”, “Component”, “System”, “Element”, “Assembly”, “Subassembly”, 
“Module” or “Submodule”. 

-311 

There are <count> active failure modes that are improperly labeled within the diagnostic model. 

-312 

Could not reallocate the size of the failure mode module array within the failure mode structure. 

-401 

The total number of failure modes for this <isolated component label>, (<module name>) does not match 
the number reported out to the Ambiguity table. Need to investigate the cause. 
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5.5 Quick-Reference Guide 

ETA Tool Command Line Syntax 


ETAT 

where 

_v6_7 {-i instrumentation 

file.csv} {-d} {-sl file.cvs} {-D} {-T} {-E} {-1} {-iso label} 

• 

{-i instrumentation tile.cvs} Specifies the CSV-formatted instrumentation file to use in the 

ETA Tool analysis. If this option is not specified, the ETA Tool 
will attempt to access a default instmmentation file by the 
naming convention “<Model Name> sensor file.csv” 

• 

{-d} 

Indicates a debugging option which turns on certain screen 
printing output for ETA Tool developers. 

• 

{-sl file.cvs} 

Indicates that the sensors sensitivity analysis is to be performed 
and the CSV-formatted file to use containing additional sensor 
information. 

• 

{-D} 

Generates the Detectability Report 

• 

{-T} 

Generates the Test Utilization Report 

• 

{-E} 

Generates the Effect Mapping Report 

• 

{-1} 

Generates the Failure Mode Isolation Report 

• 

{-iso label} 

Generates the Component Isolation report and indicates the 
hierarchical label to be used in the component-isolation analysis 


6.0 

Notes 

6.1 

Acronyms 

CPU 

Central Processing Unit 

CSV 

Comma Separated Variable 

DOS 

Disk Operating System 

ETA 

Extended Testability Analysis 

FFA 

Functional Fault Analysis 

FMEA 

Failure Mode and Effects Analysis 

GCC 

GNU C Compiler 

GLPR 

Glenn Procedural Requirement 

GRC 

Glenn Research Center 

HTML 

HyperText Manuscript Language 

ID 

Identifier 

LRU 

Line Replacement Unit 

PSV 

Pressure Selector Valve 

RAM 

Random Access Memory 

RBD 

Reliability Block Diagram 

TEAMS 

Testability Engineering and Maintenance System 
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6.2 Terms and Definitions 


TABLE 4.— CORE FAULT MANAGEMENT TERMS 1 


Tern 

Definition 

Anomaly 

The unexpected performance of intended function. 

Failure 

The unacceptable performance of intended function 

Fault 

A physical or logical cause, which explains a failure 

Root Cause 

In the chain of events leading to a failure, the first fault or environmental cause used to explain 
the existence of the failure. 


TABLE 5.— OTHER FAULT MANAGEMENT TERMS 


Tern 

Definition 

Component Isolation 

Determining the possible locations of a hypothesized failure or anomaly cause to the 
component level. For this analysis, it is not important to discriminate between failure 
modes within the component. Components may have failure modes in multiple failure 
mode groups. 

Failure Detection 

Deciding that a failure exists 1 

Failure Mode Group 

set of failure modes that are detected by the same unique detection signature 

Detection Signature 

A set of tests that detect a given failure mode 

Failure Mode 

Modes of a component’s behavior that can cause failure effects 1 

Failure Effect 

A potentially measureable change in system behavior or state property; the 
consequence(s) a failure mode has on the operation, function, or status of an item 

Isolated Failure Mode 
Group 

A failure mode group that has only one member 

Fault or Failure Mode 
Isolation 

Determining the possible locations of a hypothesized failure or anomaly cause to a 
defined level of granularity 1 

Reliability Block Diagram 

Defines the series dependence or independence of all functions of a system or 
functional group for each life-cycle event 


1 Johnson, S.B.; and Day, J.C.: NASA Constellation Program Fault Management Terminology Report, September 10, 2010. 
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Appendix A. — Diagnostic Modeling Conventions 

This section describes the diagnostic model naming conventions established by the NASA Constellation Ares I 
Functional Fault Analysis (FFA) modeling group to ensure consistency across the independently developed 
TEAMS-based subsystem models. These conventions were designed to incorporate a significant amount of system 
information intended to improve the user’s understanding of the output from the various testability analysis reports. 
For this paper, only those model elements pertinent to the ETA Tool are presented; other model elements were 
defined by the NASA developers, but are not relevant here. 

Note: A cursory knowledge of modeling in TEAMS will improve the reader’s comprehension of the following 
discussion. 

The following are a list of general syntax used throughout the naming conventions, 

• Dashes are used to separate words within a text field. 

• Underscores are used to separate text fields within a label. 

• ‘[ ]’ within a naming definition indicates an optional field. 

A-l Conventions for Tests 

Tests are assigned within test points. In general, a test can be attached to multiple test points; however, current 
modeling practice has been to create unique tests that reflect a specific test point. The test name can contain three 
distinct fields, separated by the character. The first field is a unique test name which can be a simple test 
description, such as “Fligh-Fluid-Pressure”. The second field, which is optional, is the schematic identifier for the 
sensor. The third field, which is also optional, is the unique measurement identifier usually taken from the integrated 
system measurement list. 

<Test Name/Description>[_Sensor Schematic Identifier] [_<Measurement Identified] 

For example, “Low-Turbine-Rotation_SS-l_CLVUS13534”) 

For the third field, the ETA Tool will attempt to match the “Measurement Identifier” text with either the first or 
second measurement identifier columns from the sensor information file loaded in the command line. If this field 
contains the text string, ‘Effect’, the ETA Tool interprets this as an effect test and treats it distinctly from the other 
tests. General system or subsystem conditions not aligned to a specific sensor can be represented in the diagnostic 
model with these tests identified by this ‘Effect’ text string. If any of the optional fields are unavailable, the ETA 
Tool enters a ‘None’ text value into the internal placeholder for that piece of information. The ETA Tool assumes 
that if there are only two fields available, then it is the “Sensor Schematic Identifier” field that is omitted. 

A-2 Conventions for Failure Mode Modules 

Failure mode modules are a special case module in the TEAMS diagnostic model. These modules represent the 
failures and contain the failure effects, the failure criticalities (assigned by phase), and the failure probability values. 
The failure mode module name can contain two distinct fields, separated by the ‘_’ character. The first field is the 
failure mode description. The second field contains the Failure Mode and Effects Analysis (FMEA) identifier, if 
available. 

<Failure description>[_<FMEA Identified] 

For example, Rupture_J-2X-FIDA-001 

If the optional FMEA Identifier field is unavailable, the ETA Tool enters a ‘None’ text value into the internal 
placeholder for that piece of information. 
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A-3 Conventions for Component Modules 

Within the diagnostic model, all modules that contain other modules are called component modules. These modules 
represent the breakdown structure of the system. The component module name can contain three distinct fields, 
separated by the character. The first field is the component description. The second field is optional and is the 
schematic identifier for the module, if available. The third field, which is also optional, is the Reliability Block 
Diagram (RBD) identifier usually developed for the FMEA process for the system. The RBD is a decomposition of 
the system to a level determined by the Safety and Mission Assurance analysts. Usually the RBD identifier is the 
prefix portion of the FMEA identifier. 

<Module Description>[_<Schematic Identifiers-] [_<RBD Identified] 

For example, LH2-Fill-and-Drain-Valve_HD-100_CLV-US-MPS-BB-01 

If any of the optional fields are unavailable, the ETA Tool enters a ‘None’ text value into the internal placeholder for 
that piece of information. The ETA Tool assumes that if there are only two fields available, then it is the schematic 
ID field that is omitted. 


A-4 Conventions for Technology Labels 

A set of technology labels are available for each failure mode in the diagnostic model. The ETA Tool will extract 
the technology labels from the failure mode module files (if accessible) and attempt to match the testability analysis 
switch mode settings. The format for the technology labels start with the failure mode criticality designation and end 
with the phase of operation. The phase of operation corresponds to the switch mode setting for the model. Since the 
system mode is defined by a set of switch modes, the ETA Tool program will also search the technology labels for 
any that match the system mode, if none of the switch modes were matched. 

[<Criticality>_]<Switch-Mode> 

For example, Crit-l_Phase-A 

A-5 Conventions for Switch Modes 

Switch modes are used to establish the operational configuration of a system. The TEAMS Designer uses the 
“Switch” model element to direct the propagation paths during the Testability analysis process. Switch mode names 
can include an optional subsystem prefix (e.g., MPS LOX-Tank-Repress) 

A-6 Hierarchical Labels 

Hierarchical labels are assigned to the modules of the model and are the user-defined breakdown of the modeled 
system. These labels convey the level of decomposition of the system. The model developer should assign the 
modules with care and consistency. Two special labels are utilized within the ETA Tool, 

• ‘Failure mode’ or ‘Failure Mode’ — defines the failures modeled in the system. These should be at the very 
lowest level of the hierarchical model, meaning there are no other modules under these modeled elements. 

• ‘Sensor’ — a special module label that is used only in the sensor sensitivity analysis currently and only to 
provide a distinction between failure modes detected by the sensor that are external and those detected that 
are internal to the sensor itself. For example, one of the sensor internal failure modes may result in a faulty 
signal that is detectable by a sensor test, but in the sensitivity analysis, the ETA Tool would remove that 
failure mode from the sensor’s list of failure modes that it can detect because the sensor actually was the 
cause of the failure. 
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The following hierarchical labels are currently explicitly sought out by the ETA Tool; have the following suggested 
order of system decomposition 

1. ‘Element’ — assigned at the highest level modules 

2. ‘System’ — assigned to the second highest level modules 

3. ‘Subsystem’ 

4. ‘Assembly’ 

5. ‘Subassembly’ 

6. ‘Module’ 

7. ‘Submodule’ 

8. ‘Component’ 

9. ‘RBD’ 

Note: This is only a suggested order. The user may choose to adopt a different order structure and/or may develop a 
model that has different labels altogether. 
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Appendix B. — Diagnostic Model Example 

This section presents an example system with which the ETA Tool can be applied and demonstrated. The purpose of 
the example system is to provide a reportable output that exposes the processing capabilities of the ETA Tool. 

A schematic of the example system is shown in Figure B-l. This system is a generic hydraulic actuator system that 
could drive the orientation of an aircraft or spacecraft. The system has two independently powered hydraulic 
actuators, but the power supplies are cross-strapped to provide redundancy due to loss of function at the power 
source. The hydraulic actuators and the associated power source define a subsystem and are color separated in the 
schematic and named Pitch and Yaw. In the schematic each component and line segment is designated with a name 
which is typical for system development. Also sensors are represented in the systematic as white circles or ovals. 

The hydraulic power source is a turbine pump component driven by an external propellant flow. Each hydraulic 
power source contains a reservoir and a filter. Propellant flow to the hydraulic turbines is controlled by propellant 
supply valves, PPSV and YPSV. Each actuator contains a pressure selector valve, PHPSV and YHPSV, which 
senses loss of primary supply pressure and switches over to the available secondary power source. The actuators 
also contain a power valve which controls the direction of the actuator and is controlled by an external computing 
source. 

Table B-l provides a list of sensors in the example system. The first column is the assigned schematic identifier (ID) 
for the sensor and corresponds to the designation on the schematic. The second column provides a brief description 
of the sensor. The third column is a simple sensor identifier that could possibly be used at the system controller or 
data management level. Often in system design process the same sensing element may be associated with a number 
of identifiers. The fourth and fifth columns report the tests assigned to the sensor and the periods of operation they 
are available. 



Figure B-1 . — Schematic of example system. 
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TABLE B-l.— EXAMPLE SYSTEM SENSOR LIST 


Schematic ID 

Description 

Sensor ID 

Assigned Tests 

Applied 

SSI 

Pitch Turbine Speed 
Sensor 

SEN0001 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

No-Rotation 

Flight 

Unexpected-Rotation 

Pre-Flight 






SS2 

Yaw Turbine Speed 
Sensor 

SEN0002 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

No-Rotation 

Flight 

Unexpected-Rotation 

Pre-Flight 

PV11 

Pitch Propellant Supply 
Valve Position 

SEN0003 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

PSV-Open 

Pre-Flight 

Flight 

PSV-Closed 

Pre-Flight 

Flight 

PV12 

Pitch Pressure Selector 
Valve Position 

SEN0004 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Selector- V alve-Primary- 
Position 

Pre-Flight 

Flight 

LCC-2 

Selector- V alve-Secondary- 
Position 

Pre-Flight 

Flight 

Selector-V alve-Intermediate- 
Position 

Pre-Flight 

Flight 

PV21 

Yaw Propellant Supply 
Valve Position 

SEN0005 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

PSV-Open 

Pre-Flight 
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Schematic ID Description 


Sensor ID Assigned Tests 


Applied 






Flight 

PSV-Closed 

Pre-Flight 

Flight 

PV22 

Yaw Pressure Selector 
Valve Position 

SEN0006 

Faulty-Sensor-Data 

Pre-Flight 

Flight 

Selector- V alve-Primary- 
Position 

Pre-Flight 

Flight 

LCC-2 

Selector- V alve- Secondary- 
Position 

Pre-Flight 

Flight 

Selector-V alve-Intermediate- 
Position 

Pre-Flight 

Flight 

dPl 

Pitch Delta Pressure 
Filter Sensor 

SEN0007 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

High-Delta-Pressure 

Flight 

dP2 

Yaw Delta Pressure 
Filter Sensor 

SEN0008 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

High-Delta-Pressure 

Flight 

Pll 

Pitch Turbine Propellant 
Inlet Pressure 

SEN0009 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Low-Propellant-Pressure 

Flight 

Unexpected-Propellant- 

Pressure 

Pre-Flight 

P12 

Pitch Hydraulic Supply 
Pressure 

SEN0010 

Faulty-Sensor-Data 

Pre-Flight 

Flight 

Low-Hydraulic-Pressure 

Flight 
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Schematic ID Description 


Sensor ID Assigned Tests 


Applied 





Unexpected-Hydraulic- 

Pressure 

Pre-Flight 

P21 

Yaw Turbine Propellant 
Inlet Pressure 

SEN0011 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Low-Propellant-Pressure 

Flight 

Unexpected-Propellant- 

Pressure 

Pre-Flight 

P22 

Yaw Hydraulic Supply 
Pressure 

SEN0012 

Faulty-Sensor-Data 

Pre-Flight 

Flight 

Low-Hydraulic-Pressure 

Flight 

Unexpected-Hydraulic- 

Pressure 

Pre-Flight 

Lvl 

Pitch Hydraulic 
Reservoir Level Sensor 

SEN0013 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Low -Hydraulic-Fluid-Level 

Pre-Flight 

Flight 

LCC-1 

Lv2 

Yaw Hydraulic 
Reservoir Level Sensor 

SEN0014 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Low -Hydraulic-Fluid-Level 

Pre-Flight 

Flight 

LCC-1 

Curl 1 

Pitch Propellant Supply 
Valve Current 

SEN0015 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

No-Electrical-Power 

Flight 

Cur 12 

Pitch Actuator Power 
Valve Solenoid A 
Current 

SEN0016 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

No-Current 

Flight 
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Schematic ID 

Description 

Sensor ID 

Assigned Tests 

Applied 

Cur 13 

Pitch Actuator Power 
Valve Solenoid B 
Current 

SEN0017 

F aulty-S ensor-Data 

Pre-Flight 

Flight 



No-Current 

Flight 

Cur2 1 

Yaw Propellant Supply 
Valve Current 

SEN0018 

F aulty-S ensor-Data 

Pre-Flight 

Flight 




No-Electrical-Power 

Flight 

Cui-22 

Yaw Actuator Power 
Valve Solenoid A 
Current 

SEN0019 

F aulty-S ensor-Data 

Pre-Flight 

Flight 



No -Current 

Flight 

Cur23 

Yaw Actuator Power 
Valve Solenoid B 

SEN0020 

F aulty-S ensor-Data 

Pre-Flight 

Flight 




No -Current 

Flight 

D1 

Pitch LVDT 

SEN0021 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Displacement Transducer 

No-Position-Change 

Flight 




Actuator-Position-Errors 

Flight 

D2 

Yaw LVDT 

SEN0022 

F aulty-S ensor-Data 

Pre-Flight 

Flight 

Displacement Transducer 

No-Position-Change 

Flight 




Actuator-Position-Errors 

Flight 

P13 

Pitch Hydraulic Return 
Pressure 

SEN0023 

Faulty-Sensor-Data 

Pre-Flight 

Flight 




Low-Pressure 

Flight 

P23 

Yaw Hydraulic Return 
Pressure 

SEN0024 

Faulty-Sensor-Data 

Pre-Flight 

Flight 




Low-Pressure 

Flight 
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Table B-2 provides a simple Failure Modes and Effects Analysis (FMEA) for the system. For a typical FMEA the 
system is broken down into a set of components. The level to which a given system is broken down is dependent on 
the system analysts. The failure modes for each component are compiled and the effects and impacts of those 
failures during various phases of operation are determined. Based upon the impact of the failure to the overall 
system, a criticality value is assigned. For our analysis example the following criticality were used, 

‘ 1 ’ — Loss of system causing a safety hazard that could cause loss of life or vehicle 

‘ 1R’ — Loss of redundancy where a similar second fault would cause a criticality 1 scenario 

‘IS’ — Loss of system safety feature which puts the system at risk in the event of a particular criticality 1 

failure. This includes sensor loss where the sensor could be monitoring a failure condition. 

‘2’ — Loss of system function that could compromise overall mission success 
‘None’ — No impact on system function 

Table B-2 lists the name of the component, all the schematic identifiers of the components in this system and a 
description of the component. For each component, all the failure modes are listed with a description of the failure, 
and the effects assigned and criticality for each phase of operation. For this example, three operational phases were 
established: Phase A (system dormant phase), Phase B (system operating phase) and Phase C (system recovery 
phase which is intended to represent possible failure effects during recovery from loss of a single hydraulic supply 
circuit). 


NASA/CR— 20 11-21 7240 


50 



TABLE B-2.— EXAMPLE SYSTEM FMEA 


Component 

Schematic 

ID 

Description 

FMEA ID 

Failure Mode 

Phase A 

(Non-Operating) 

Criticality 

Phase B 
(Operating) 

Criticality 

Phase C 
(Recovery 
Phase) 

Criticality 

Hydraulic Turbine 

PTURB 

YTURB 

Hydraulic turbine 
transfers propellant 
flow to rotational 
energy 

MS-SS-HPump-01- 

001 

Fail to generate 
rotational energy 

None 

None 

Low-Rotation 

1R 

None 

None 

MS-SS-HPump-01- 

002 

External Leakage of 
propellant 

None 

None 

Propellant-Leak 

3 

None 

None 

Hydraulic Pump 

PPUMP 

YPUMP 

Hydraulic pump 
converts rotational 
energy into hydraulic 
pressure 

MS-SS-HPump-02- 

001 

Fails to produce 
hydraulic pressure 

None 

None 

Low-Hydraulic-Pressure 

1R 

None 

None 

MS-SS-HPump-02- 

002 

External Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss 

1R 

Hydraulic-Fluid-Loss 

1R 

None 

None 

Upstream 
Propellant Line 
Segments 

PPLIN1 

PPLIN2 

YPLIN1 

YPLIN2 

Propellant line 
segments that are 
upstream of the 
propellant supply 
valve 

MS-SS-HPump-03- 

001 

External Leakage of 
propellant 

Propellant-Leak 

2 

Propellant-Leak 

Low-Propellant-Flow 

Low-Propellant- 

Pressure 

1R 

None 

None 

Midstream 
Propellant Line 
Segments 

PPLIN3 

YPLIN3 

Propellant line 
segments that are 
between the propellant 
supply valve and 
Turbine 

MS-SS-HPump-04- 

001 

External Leakage of 
propellant 

None 

None 

Propellant-Leak 

Low-Propellant-Flow 

Low-Propellant- 

Pressure 

1R 

None 

None 

Propellant Check 
Valve 

PPCKVAL 

YPCKVAL 

Check valves in the 
propellant lines that 
prevent flow back to 
the main propulsion 
supply system. 

MS-SS-HPump-06- 

001 

Fails to open 

None 

None 

Low-Propellant-Flow 

1R 

None 

None 

MS-SS-HPump-06- 

002 

External Leakage of 
propellant 

Propellant-Leak 

2 

Propellant-Leak 

Low-Propellant-Flow 

Low-Propellant- 

Pressure 

1R 

None 

None 

MS-SS-HPump-06- 

003 

Internal Leakage 

Propellant-Leak 

2 

None 

None 

None 

None 

Propellant Supply 
Valve 

PPSV 

YPSV 

Propellant supply 
valve. Energized to 
open. 

MS-SS-HPump-07- 

001 

Fails to Open 

None 

None 

Low-Propellant-Flow 

Low-Propellant- 

Pressure 

Valve-Closed 

1R 

None 

None 

MS-SS-HPump-07- 

002 

Fails to Close 

Unexpected-Propellant- 

Flow 

Valve-Open 

2 

None 

None 

Unexpected- 

Propellant-Flow 

Valve-Open 

IS 
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TABLE B-2. — Continued. 


Component 

Schematic 

ID 

Description 

FMEA ID 

Failure Mode 

Phase A 

(Non-Operating) 

Criticality 

Phase B 
(Operating) 

Criticality 

Phase C 
(Recovery 
Phase) 

Criticality 

(continued) 

(continued) 

(continued) 

MS-SS-HPump-07- 

003 

External Leakage of 
propellant 

Propellant-Leak 

2 

Propellant-Leak 

Low-Propellant-Flow 

Low-Propellant- 

Pressure 

1R 

None 

None 

MS-SS-HPump-07- 

004 

Internal Leakage 

Unexpected-Propellant- 

Flow 

Propellant-Leak 

2 

None 

None 

None 

None 

Hydraulic Supply 
Lines 

PHLIN01 

PHLIN02 

PHLIN03 

PHLIN04 

PHLIN05 

PHLIN06 

YHLIN01 

YHLIN02 

YHLIN03 

YHLIN04 

YHLIN05 

YHLIN06 

Hydraulic fluid lines 
that supply high 
pressure hydraulic 
fluid to actuator 

MS-SS-HYD-0 1 -00 1 

External Leakage of 
hydraulic fluid 

Hydraulic -Fluid-Loss 

1R 

Hydraulic -F luid-Loss 

1R 

None 

None 

Hydraulic Supply 
Lines - DS of 
Selector Valve 

PHLIN06 

YHLIN06 

Hydraulic fluid lines 
that supply high 
pressure hydraulic 
fluid to actuator 

MS-SS-HYD- 10-00 1 

External Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss-DS 

1 

Hydraulic-Fluid-Loss- 

DS 

1 

Hydraulic- 

Fluid-Loss- 

DS 

i 

Hydraulic Return 
Lines 

PHLIN08 

PHLIN09 

PHLIN10 

PHLIN11 

YHLIN08 

YHLIN09 

YHLIN10 

YHLIN11 

Hydraulic fluid lines 
that return low 
pressure hydraulic 
fluid from actuator 

MS-SS-HYD-02-00 1 

External Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss 

1R 

Hydraulic-Fluid-Loss 

1R 

None 

None 
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TABLE B-2. — Continued. 


Component 

Schematic 

ID 

Description 

FMEA ID 

Failure Mode 

Phase A 

(Non-Operating) 

Criticality 

Phase B 
(Operating) 

Criticality 

Phase C 
(Recovery 
Phase) 

Criticality 

Hydraulic 
Return Lines - 
DS of Selector 
Valve 

PHLIN07 

YHLIN07 

Hydraulic fluid 
lines that return 
low pressure 
hydraulic fluid 
from actuator 

MS-SS-HYD-1 1-001 

External 
Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss-DS 

1 

Hydraulic-Fluid-Loss- 

DS 

1 

Hydraulic- 

Fluid- 

Loss-DS 

1 

Hydraulic 
Check Valve 

PHCKVAL 

YHCKVAL 

Allow forward 
pressurized flow 

MS-SS-HYD-03-00 1 

Fails to open 

None 

None 

Low-Hydraulic- 

Pressure 

1R 

None 

None 



of hydraulic fluid 

MS-SS-HYD-03-003 

External 
Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss 

1R 

Hydraulic-Fluid-Loss 

1R 

None 

None 

Hydraulic Filter 

PHFILT 

YHFILT 

Filter the 
hydraulic fluid 

MS-SS-HYD-04-00 1 

Flow Blockage 

None 

None 

NoHydraulicPressur 

e 

High Delta Pressure 

1R 

None 

None 




MS-SS-HYD-04-002 

External 
Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss 

1R 

Hydraulic-Fluid-Loss 

1R 

None 

None 

Hydraulic 

Reservoir 

PHRES 

YHRES 

Store hydraulic 
fluid and provide 
pump inlet 
pressure 

MS-SS-HYD-05-00 1 

Lose bootstrap 
pressure 

None 

None 

NoPumpInletPress 

ure 

1R 

None 

None 



MS-SS-HYD-05-002 

External 
Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss 

1R 

Hydraulic-Fluid-Loss 

1R 

None 

None 

Hydraulic 
Pressure 
Selector Valve 

PHPSV 

YHPSV 

Hydraulic 
pressure selector 
which switches 
from primary to 

MS-SS-ACT-01-001 

Stuck in an 

intermediate 

position 

Selector- Valve- 
Intermediate-Position 

1 

Selector- Valve- 
Intermediate-Position 

1 

Selector- 

Valve- 

Intermedia 

te-Position 

i 



secondary power 
source with loss 
of hydraulic 
pressure 

MS-SS-ACT-01-002 

Stuck in the 
primary position 

None 

None 

None 

None 

Low- 

Hydraulic- 

Pressure 

Selector- 

Valve- 

Position- 

Primary 

IS 




MS-SS-ACT-01-003 

Stuck in the 

secondary 

position 

None 

None 

Selector- Valve- 
Position-Secondary 

1R 

None 

None 




MS-SS-ACT -0 1 -004 

External 
Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss-DS 

i 

Hydraulic-Fluid-Loss- 

DS 

1 

Hydraulic- 

Fluid- 

Loss-DS 

i 
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TABLE B-2. — Continued. 


Component 

Schematic ID 

Description 

FMEA ID 

Failure Mode 

Phase A 

(Non-Operating) 

Criticality 

Phase B 
(Operating) 

Criticality 

Phase C 
(Recovery 
Phase) 

Criticality 

Hydraulic Power 
Valve 

PHPOWVAL 

YHPOWVAL 

Controls hydraulic 
power to drive the 
actuator 

MS-SS-ACT-02-00 1 

Stuck in an operating 
position (A or B) 

None 

None 

Actuator-Full-Extend 

1 

Actuator-Full- 

Extend 

1 

MS-SS-ACT-02-002 

Stuct in NULL 
position 

None 

None 

No- Actuator-Movement 

1 

No- Actuator- 
Movement 

1 

MS-SS-ACT-02-003 

External Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss-DS 

i 

Hydraulic-Fluid-Loss- 

DS 

1 

Hydraulic- 

Fluid-Loss-DS 

1 

Actuator 

PACT 

YACT 

hydraulic actuator 

MS-SS-ACT-03-001 

Actuator locked in 
place 

None 

None 

No- Actuator-Movement 

1 

No- Actuator- 
Movement 

1 

MS-SS-ACT-03-002 

External Leakage of 
hydraulic fluid 

Hydraulic-Fluid-Loss-DS 

i 

Hydraulic-Fluid-Loss- 

DS 

1 

Hydraulic- 

Fluid-Loss-DS 

1 

MS-SS-ACT-03-003 

Actuator detaches 
from hinge point 

None 

None 

Actuator-Uncontrollable 

1 

Actuator- 

Uncontrollable 

1 

Turbine Speed 
Sensor 

551 

552 

Measures the rotation 
speed of the turbine 

MS-SS-HPump-08- 

001 

Faulty signal 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Propellant Supply 
Valve Position 

PV11 

PV21 

Measures the 
propellant supply 
valve position 

MS-SS-HPump-09- 

001 

Faulty signal 

Faulty- Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Pressure Selector 
Valve Position 

PV12 

PV22 

Measures the pressure 
selector valve position 

MS-SS-ACT-04-00 1 

Faulty signal 

Faulty- Signal 

IS 

Faulty-Signal 

IS 

FaultySignal 

IS 

Delta Pressure 
Filter Sensor 

dPl 

dP2 

Measures the pressure 
difference across the 
hydraulic filter 

MS-SS-HYD-06-00 1 

Faulty signal 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Turbine Propellant 
Inlet Pressure 
Sensor 

Pll 

P21 

Measures the inlet 
pressure for the 
turbine 

MS-SS-HPump- 1 0- 
001 

Faulty signal 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Hydraulic Supply 
Pressure 

P12 

P22 

Measures the 
hydraulic supply 
pressure 

MS-SS-HYD-07-00 1 

Faulty signal 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 
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TABLE B-2. — Concluded. 


Component 

Schematic 

Description 

FMEA ID 

Failure Mode 

Phase A 

Criticality 

Phase B 

Criticality 

Phase C 

Criticality 


ID 




(Non-Operating) 


(Operating) 


(Recovery 











Phase) 


Hydraulic 

Lvl 

Measures the 

MS-SS-HYD-08-00 1 

Faulty signal 

Faulty- Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Reservoir Level 

Lv2 

hydraulic fluid level 









Sensor 


in the reservoir 









Propellant Supply 

Curl 1 

Measures the current 

MS-SS-HPump-1 1- 

Faulty signal 

Faulty- Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Valve Current 

Cur21 

supplied to the 
propellant supply 
valve 

001 








Actuator Power 

Cur 12 

Measures the current 

MS-SS-ACT-05-00 1 

Faulty signal 

Faulty-Signal 

IS 

Faulty- Signal 

IS 

Faulty-Signal 

IS 

Valve Solenoid 

Cur 13 

supplied to the power 









Current 

Cur22 

Cur23 

valves solenoids 









LVDT 

D1 

Measures the linear 

MS-SS-ACT-06-00 1 

Faulty signal 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Displacement 

D2 

displacement of the 









Transducer 


actuator 









Hydraulic Return 

P13 

Measures the 

MS-SS-HYD-09-00 1 

Faulty signal 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Faulty-Signal 

IS 

Pressure 

P23 

hydraulic return 
pressure 
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With the schematic, sensor listing and FMEA, a diagnostic model was generated in TEAMS Designer. The entire 
model is called Basic JSystem. At the top-level view of the Basic System model, shown in Figure B-2, the entire 
system consists of the Vector-Control-System and two external systems, External-Propellant-Supply-System and 
Avionics. These two external systems have failure modes that could introduce effects into the system model being 
analyzed. Also displayed are two system effect testpoints that represent the impact of the vehicle to failure effects. 

Figure B-3 shows the further breakdown of the system model, Vector-Control-System. Similar to the schematic, the 
diagnostic model creates two distinct effect flow paths, one for the Pitch actuator and the other for the Yaw actuator. 
Each flow path is further broken up into components or groups of components, called assemblies. Note that the 
Component modules in this figure are internally labeled with ‘Component’, this being their assigned hierarchical 
label. For the assemblies, four are assigned a hierarchical label of ‘Assembly’, but two have a label of ‘LRU’. This 
is to facilitate demonstration of the ambiguity analysis applied to component replacement requirements. 

Each assembly is further disseminated into components. Figures B-4, B-5, and B-6 display the Propellant Inlet 
Assembly, the Flydraulic Pump Assembly and the Hydraulic Fluid Assembly, respectively. Note that in this model 
individual line segments are modeled distinctly. Also displayed in the assembly figures are the defined testpoints 
that are linked to the sensor components. The color coding of the links between modules and testpoints help in the 
visual review of the model, but do not affect the model operation or the testability analysis. 

Each component can contain various modules including failure mode modules, effect mapping modules and even 
other components. Figure B-7 is the internal view of the Hydraulic Power valve component. The failure modes align 
to failure modes defined in the example FMEA, Table B-2. 



Figure B-2. — Top-level module representation of the example diagnostic model displayed within the 
TEAMS Designer interface. 
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Figure B-3. — Module breakdown of the example model viewed with TEAMS Designer interface. 
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Figure B-4. — Example diagnostic propellant inlet assembly module displayed within TEAM Designer interface. 
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Figure B-5. — Example diagnostic hydraulic pump assembly module displayed within TEAM Designer interface. 
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Figure B-6. — Example diagnostic hydraulic fluid assembly module displayed within TEAM Designer interface. 
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Figure B-7. — Internal view of the hydraulic power valve component within TEAM Designer interface. 
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